Computerized transaction execution and processing requires an enormous, and often detrimental, amount of time and resources. The time and resources are required because, in most instances, execution and processing are based upon customized implementations of the transaction.
Customized transaction implementations require new programming. New programming requires cost and effort—not only for the first attempt, but also for the debugging and testing processes. Moreover, once the program is debugged and released, real world implementations require yet further testing and debugging.
All this effort takes resources and time. It takes resources because the programmers must first develop the program with input from the users, and then the users themselves must test the program in the field, to ensure reliable operation. The effort required means that the users may be too busy doing their job to assist in programming efforts. Thus the program may not ever be developed. Moreover, by the time any particular program is developed, the markets may have shifted away from the initial transactional conditions that first provided the impetus for developing the program. For example, specific trading strategies are usually constructed and executed on a customized basis, yet by the time the program is developed for those strategies, and those strategies are executed, they may be no longer useful.
The cost, effort and time factors are not solely the result of required programming. In trading transactions, the programmers must be advised by the traders or other business professionals regarding desired trading strategies and desired markets. These professionals are busy in their own right—they may have little or no time to advise the programmers on what new strategies and markets should be developed. Even if they can advise the programmers, trading strategies can become quite complex, and in order to communicate those strategies and implement those strategies effectively, the programmer and trader interactions cost time, money and resources.
Enterprise-wide customization adds yet another level of time, effort and complexity. What may be useful in one enterprise business unit may not be useful in another, and time, effort and resources may not be available to implement specific programs customized for each business unit.
Any implementations must be quite robust, and reliably and consistently execute trading strategies. The implementation of new computerized transactional programs must be as close to bullet proof as possible—failure of a trading program can mean losses in thousands, millions or even billions of dollars. Developing reliable implementations of trading programs means that testing procedures and recovery procedures must always be paramount considerations.
Finally, the interfaces to the programs used in trading systems need to be improved to provide improved functionality and ease of use.
Accordingly, it is an object of at least an embodiment of the invention to provide apparatus, methods and articles of manufacture for an interface for constructing and executing transactions.
It is a further object of at least an embodiment of this invention to provide open-ended apparatus, interfaces, methods and articles of manufacture for constructing and executing transaction processes and programs.
It is a further object of at least an embodiment of this invention to provide robust and reliable apparatus, methods and articles of manufacture for a user interface for implementing trading strategies.
The scope of the invention is not limited in any way by the objects. Further objects will become evident in the description that follows, and in part will be obvious from the description, or may be learned by practice of the invention.